Whiteline: Alpha

home *** CD-ROM | disk | FTP | other *** search

/ Whiteline: Alpha / Whiteline Alpha.iso / progtool / gfabasic / gfa_bugs.txt

Wrap

Text File | 1994-09-22 | 28.0 KB | 528 lines

@(#) bugs.txt, Fehler in GFABASIC 3.x - Uwe Ohse, 15.4.93 Liste des Grauens - willkommen im Land der Bugs! Dieser Text führt die mir bekannten fehlerhaften oder prinzipiell nicht zukunftssicheren Befehle im GFABASIC 3.6. Er ist nicht als vollständig zu betrachten! Die Anzahl mir unbekannter Fehler im GFABASIC 3.6 ist mög- licherweise sehr hoch. 1. Die GFA-Fensterverwaltung. Die einfache Fensterverwaltung mit OPENW, CLOSEW usw. ist in früheren Versionen fehlerhaft gewesen. Wie es heute aussieht, weiß ich nicht, da ich schon lange auf direkte AES-Aufrufe umgestiegen bin. Prinzipiell jedoch ist ein gravierender Mangel nicht beseitigt worden: Es können mit den GFA-Fensterbefehlen nur bis zu vier Fenster verwaltet werden, was in Zukunft ein ernsthafter Mangel werden dürfte. Auch ist die GFA-Fensterverwaltung recht unflexibel. Die GFA-Fensterverwaltung kann übrigens mit großen Fensterhandles (WINX, MultiTOS) umgehen. 2. Die Dateifunktionen unter Multitasking Tritt bei OPEN ein Fehler auf, z.B. weil gerade ein anderer Prozess die Datei gesperrt hat, so meldet GFABASIC sofort einen Fehler. Damit sind die gesamten I/O-Operationen unter MTOS/MiNT ziemlich unsicher, und es ist nicht möglich, z.B. zwei Bugsicprogramme auf denselben Datenbestand loszulassen. Für dieses Problem gibt es bisher keine Lösung außer der Verwendung des GFA-nach-C-Konverters (gut, aber für den Hobbygebrauch etwas teuer) oder einer selbstgeschriebenen Ein/Ausgabelibrary auf GEMDOS()-Basis. Letztere verlangsamt das Programm recht stark, falls sie nicht in Assembler realisiert wird. 3. Bekannte Bugs, die nicht auf einen speziellen Befehl beschränkt sind 3.1 Allgemein - GFABASIC verläßt sich darauf, daß VDI-Aufrufe den Inhalt von CONTROL(6) (das Handle der Workstation) nicht verändern. Dies ist eine undokumentierte Eigenschaft einiger VDI-Versionen, die andere Versionen nicht teilen. Mit anderen Worten: Möglicherweise steht nach dem Aufruf einer VDI-Funktion etwas ganz anderes in Control(6) als vorher. Und beim nächsten Aufruf stimmt das Handle nicht -> im schlimmsten Falle Crash! Abhilfe: Nach _jedem_ VDI-Aufruf CONTROL(6) setzen, z.B. mit V~H=xxx. (was definitiv zuviel verlangt ist, ich weiß) - Außerdem unterscheidet sich die Syntax einiger VDI-Aufrufe (rund um das Öffnen und Schließen von virtuellen oder physikalischen Workstations) stark von der in anderen Sprachen gebräuchlichen. 3.2 Compiler - Bitte "kommentieren" Sie mal einen Block oder eine Zeile in ihrem Programm mit "IF FALSE" und "ENDIF" aus und compilieren sie es dann. In vielen Fällen stürzt der Compiler während der Arbeit bombenwerfend ab. - Konstruktionen wie "IF exist(datei$)" können unter Umständen im compilierten Programm falsch ausgewertet werden. Verwenden Sie besser "IF exist(datei$)<>FALSE". Dieser unangenehme Effekt ist mehr oder weniger unbekannt und nicht beliebig reproduzierbar. Eines meiner Programme findet aber erst seit der Änderung der EXIST-Bedingungen seine sämtlichen Dateien wieder. Auch ein beim Mailboxprogramm Q_MAIL aufgetretener Effekt ist nur so erklärbar gewesen. Eine Programmteil der Form IF EXIST(zugriffsliste$) [lesen der Liste] ELSE [neuanlegen der Liste] ENDIF führte ab und zu (wenn auch selten) dazu, daß eine existierende Liste gegen die Defaultliste "ersetzt wurde". Ähnliches für alle anderen "Vergleiche irgendwas" Bedingungen, also auch für WHILE und UNTIL. Die Probleme lassen sich nicht vernünftig reproduzieren (und schon gar nichts in ein paar Zeilen), sind aber mittlerweile von genügend anderen Leuten bestätigt worden. - in einem relativ großen Programm (undokumentiert 250 K) ist es vorgekommen, daß der Compiler Funktionen nicht gefunden hat, wenn sie hinter den Funktionen standen, aus denen sie aufgerufen wurden. Abhilfe brachte es, die in der Hierarchie niedrigeren Funktionen vor den anderen zu plazieren. - TT? führt auf Geräten ohne Cookiejar zum Absturz, da hier einfach unterstellt wird, daß eine FPU vorhanden ist. 3.3 Interpreter - Der Interpreter greift in starkem Maße auf LineA zu. Schaltet man z.B. unter NVDI das LineA ab, funktioniert der Interpreter nicht mehr. - Er verbiegt auch Systemvektoren ohne die dafür vorgesehene Betriebs- systemfunktion setexc zu verwenden. Damit ist er unter MiNT und MultiTOS nicht mehr lauffähig. (Es sei denn, man patcht ihn. Siehe unten). 3.4 Linker - Das Anlegen von Symboltabellen sollte man bei längeren Programmen unterlassen. Der Linker kann abstürzen. 3.5 Speicherverwaltung in Interpreter und Compiler - RESERVE arbeitet unter TOS 3.06 und MiNT nur unzureichend. Es kann den einmal freigegebenen Speicher nicht wieder vergrößern. Dies war GFA vor der Auslieferung von Bugsic 3.6 bekannt und ist nicht behoben worden. Man denke darüber, wie man will. Die einzige Abhilfe ist, auf eine dynamische Speicherverwaltung mit Malloc umzusteigen. Leider unterstützt GFABASIC dies in keiner Weise. Unter MultiTOS wird die damit erzwungene starre Speicherverwaltung ärgerlich werden. - Die Speicherverwaltung ist nicht nur unflexibel, sondern auch fehlerhaft. Mit freundlicher Erlaubnis von Christoph Conrad @ AC3: Probieren Sie mal folgendes (danach neu booten): ' Compilerversion mit $m statt RESERVE RESERVE 1000 $m 4711 ' RESERVE damit's etwas schneller abstürzt, aber eigentlich unnötig. ' Die (**) Zeilen braucht man beim Interpreter, damit nach dem RESERVE ' auch wirklich (FRE() MOD 16) == 0 gilt ' minus 4: wegen Backtrailer bei rest16$ beim Compiler falls $m XXXX ' mit (XXXX MOD 16)<>0 rest16%=(FRE(0) MOD 16)-4 ! ** IF rest16%<0 ! ** ADD rest16%,16 ! ** ENDIF ! ** rest16$=STRING$(rest16%,0) ! ** ' (FRE() MOD 16) == 0 jetzt erfüllt str$="AHAH" DO @crash(str$) LOOP PROCEDURE crash(str$) str$="OHOH" RETURN ' (Der Bug ist nicht auf jedem Rechner zu jeder Zeit reproduzierbar, ' z.B. tritt er auf meinem TT nicht auf, auf dem STE aber schon. Uwe) - Ein weiterer Bug in der internen Speicherverwaltung tritt unter noch selteneren Umständen auf, es ist mir bisher nicht gelungen, ihn in kleineren Programmen zu reproduzieren. Er tritt im Zusammenhang mit der Übergabe lokaler Variablen als Parameter an eine Prozedur oder Funktionen besonders gerne auf, wenn man dabei Call-by-Reference- und Call-by-Value-Parameter mischt und nach Möglichkeit auch Felder übergibt. Die Folgen reichen von kompletten Systemhängern bis zu einigermaßen zivilisierten, aber vollkommen falschen Fehlermeldungen des Interpre- ters. Abhilfe: CbV- und CbR-Parameter nach Möglichkeit nicht mischen, Felder nach Möglichkeit nur eine Prozedur tief hinunterreichen (?). Nachtrag: PROCEDURE test LOCAL a& ' adr%=V:a& !Adresse von a& vorher PRINT adr% ' a&=@zahl !Funktion aufrufen ' PRINT a& !a& => falsch <= ERROR hier! ' PRINT V:a& !Adresse von a& nachher = verschoben!! PRINT WORD(adr%) !An der alten Adresse steht es RETURN FUNCTION zahl DIM a$(10) !Hier verschiebt sich die Adresse von a& ! RETURN 10 ENDFUNC Ausgabe beispielsweise: 1000000 (beliebige, noch korrekte Adresse) 42 (irgendeine Zahl) 2000000 (beliebige Adresse ungleich der obigen) 10 In anderen Fällen treten solche Probleme in der Funktion "zahl" auf, wenn dort z.B. die Variable a benutzt wird. Konsequenz daraus: Vorsicht mit lokal deklarierten Feldern! (u.a.) Gruppe: GFABASIC ID : A1724@PB2 Kommentar zu A9378@OS Wg. : Bugs: Teil 2 (Befehle) Von : Uwe Ohse @ PB2 (Fr, 16.04.93 10:15) 4. Diverse fehlerhafte oder unbrauchbare Befehle: Im folgenden bedeutet LA LINE-A! ACHAR: ruft LA (Textblt) auf. Abhilfe: TEXT ACLIP: ruft LA auf. Abhilfe: CLIP. AFTER: hängt von $I+ ab und sollte deshalb vermieden werden. Abhilfe bieten die AES-Events (EVNT_TIMER, EVNT_MULTI) oder zur Not auch ON MENU. ALINE: ruft LA (Arbitrary line) auf. Abhilfe: LINE APOLY: ruft LA (Filled polygon) auf. Abhilfe. POLYLINE ARECT: ruft LA (Filled rectangle) auf. Abhilfe: PBOX ATEXT: ruft LA (TextBlt) auf. Abhilfe: TEXT BITBLT: Die Varianten BITBLT adresse% und BITBLT ein_feld%() benutzen LA (Bitblt) und sind deshalb unsauber. Als Abhilfe bietet sich die Benutzung von BITBLT q%(),z%(),d%() an. Hier wird das VDI benutzt. Anmerkung: Leider ist dies der einzige saubere Rasterkopierbefehl, den Bugsic bietet. CALL: Funktioniert im Interpreter nicht. Abhilfe bietet folgender Patch von Christoph Conrad: (3.6 D TT - Groesse 104770) Byte: Dateioffset $34AC. Dort sollten die Bytes $48 $ E7 $ 00 $ 0A zu finden sein. Das $0A in $0E umpatchen, das wars. CRSCOL: greift auf LA-Variablen zu. Abhilfe: Keine. Es sollte aber nicht schwierig sein, sich die Cursorposition zu merken! CRSLIN: greift auf LA-Variablen zu. Siehe CRSCOL. DEFMOUSE: greift auf LA zu, um die Mausform sofort zu ändern. Schaltet man unter NVDI das LA ab, wird die Mausform erst bei der nächsten Mausbewegung geändert. Abhilfe: GRAF_MOUSE() (ist sowieso sauberer). EVERY: hängt von $I+ ab und sollte vermieden werden. Abhilfe: Siehe AFTER. EXEC: Modus 4 funktioniert offenbar nur zufällig. FILESELECT: schaltet die Maus mit LA ab. Abhilfe: FSEL_(EX)INPUT benutzen. GET: in einen String passen nur 32K, und das reicht schon unter Overscan u.U. nicht mehr aus. Man sollte sich auch nie darauf verlassen, daß 100*100 Pixel in den String passen: Es könnte z.B. eine TrueColor-Karte laufen. Weiterhin benutzt GET die LineA-Variable M_HID_CT und Logbase (XBios(3)). Abhilfe: VDI-BITBLT. HIDEM: ruft LA (Hide mouse) auf. Abhilfe: GRAF_MOUSE() HLINE: ruft LA (Horizontal line) auf. Abhilfe: LINE. INPUT: greift u.U. auf LA-Variablen zu. Leider hilft es auch nicht, CON: zum Lesen zu öffnen und INPUT # zu benutzen: So schlau ist Bugsic leider. Abhilfe: In GEM-Programmen Dialoge benutzen oder gleich in Fenstern arbeiten, in TOS-Programmen GEMDOS(10,...) (=Cconrs) benutzen. Nachtrag: Es hilft auch, mit INPUT # von "STD:" zu lesen, diese Variante benutzt kein LA und ermöglicht auch eine I/O-Umlenkung. In GEM-Programme passt sie allerdings nicht (dasselbe gilt allerdings auch für INPUT). INP?: benutzt LA. Abhilfe: BIOS(1,device) INSTR: Die Varianten INSTR("xyz","xyz",2) und INSTR(2,"xyz","xyz") liefern 1 zurück, obwohl "xyz" in "yz" nicht vorhanden ist. KEYDEF: hängt von $I+ ab und ist deshalb zu meiden. Abhilfe: in GEM-Programmen simpel, bei Eintreffen eines Tastaturereignisses statt der Funktionstaste die entsprechenden Strings verarbeiten. In TOS-Programmen wird es schwieriger, ich persönlich glaube auch nicht, daß die benutzung der Funktionstasten in reinen TOS-Programmen schön ist und gebe hierzu konsequenterweise keinen Tip. L~A: die Basisadresse der LA-variablen persönlich. Sozusagen der Teufel selbst. Für die allermeisten Zwecke braucht man sowieso keinen Zugriff darauf. Wenn doch, tja, dann muß man halt. MOUSE, MOUSEX, MOUSEY, MOUSEK: greifen auf LA-Variablen zu. Abhilfe bietet mal wieder das AES, wenn man auf Mausereignisse abfragt (EVENT_MULTI, EVENT_BUTTON, EVENT_MOUSE) oder (einfacher) GRAF_MKSTATE verwendet. POS(): benutzt zwar kein LA, ist aber trotzdem unbrauchbar, da es ganz einfach "Anzahl der seit dem letzten Carriage Return ausgegebenen Zeichen modulo 256" zurückzugibt und nicht die tatsächliche Cursorposition! PRINT: gibt normalerweise über das BIOS aus. Arbeitet man aber mit PRINT#x, wenn x mit OPEN "O",x,"STD:" geöffnet ist, wird über die Standardausgabe ausgegeben. Diese Variante ist für Tools, bei denen eine Ein/Ausgabeumlenkung denkbar ist, vorzuziehen! PRINT auf Bildschirm oder STD: Hat in GEM-Programmen zu nichts zu suchen! PSET: ruft LA (Put pixel) auf. Abhilfe: PLOT PTST: ruft LA (Get pixel) auf. Abhilfe: POINT() PUT: Da GET nicht ausreichend verläßlich arbeitet, ist auch PUT nicht zu gebrauchen. RC_COPY: ruft LA (BltBlt) auf. Abhilfe: Siehe BITBLT. RESERVE: ist fehlerhaft. Unter TOS 3.06 und MiNT kann RESERVE den Speicher nicht wieder vergrößern. Abhilfe: Möglichst nur einen RESERVE benutzen, nämlich den zum Verkleinern des Arbeitsspeichers, oder diese Option zumindest unter MiNT/TOS3.06 anbieten, oder auf dynamische Speicherverwaltung mittels MALLOC umsteigen. RESUME: hängt von $I+ ab und sollte deshalb vermieden werden. Abhilfe: RESUME label. Auch hier heißt es aufpassen, da bei RESUME label der GFA-interne Stack inkonsistent wird. Ein Rücksprung (RETURN) aus einem Unterprogramm ist deshalb nicht sicher möglich, der RESUME label sollte also in eine Prozedur führen, die nicht wieder verlassen werden muß, z.B. das Hauptprogramm. (Ich erbitte mir Tips hierzu!) RESUME NEXT: hängt von $I+ ab und sollte deshalb vermieden werden. Abhilfe: Siehe RESUME. SETCOLOR: benutzt das XBIOS. Getreu der Regel, daß man Betriebssystemaufrufe unterschiedlicher Ebenen nicht mischt, sollte man stattdessen VSETCOLOR verwenden, wenn man mit den VDI-Aufrufen zeichnet. SETMOUSE: ändert LA-Variablen. Abhilfe: APPL_TPLAY, leider deutlich komplizierter. SGET: in einen String passen nur 32K, und das reicht schon unter Overscan ganz sicher nicht aus. Abhilfe: VDI-BITBLT. SPUT: Wenn SGET nicht zu gebrauchen ist, fällt auch SPUT aus. SHOWM: ruft LA (Show mouse) auf. Abhilfe: GRAF_MOUSE SPRITE: ruft LA (Draw sprite, Undraw sprite) auf. Abhilfe: viel Mehrarbeit. Im allgemeinen benötigt man Sprites sowieso nur in Spielen, und für die gelten andere Regeln. STE?: Arbeitet grob fehlerhaft: Ist kein Cookiejar angelegt, so ange- nommen, das Programm liefe auf einem ST, sonst wird der Cookie _SND abgefragt, ob das Bit für Stero/DMA-Sound gesetzt ist. Somit macht Bugsic von der Soundhardware abhängig, auf welcher Maschine das Programm läuft. Was passiert auf dem Falcon? Mög- licherweise alles schlechte der Welt. Abhilfe: Den _MCH-Cookie selbst abfragen. STICK: sollte vermieden werden. Unter MultiTOS dürfte es sehr unschön sein, wenn eine Applikationen den Mausport als Joystick schaltet. STICK(): Benutzt KbdvBase = XBios(34) und Bconout(Ikbdsys) = Bios(3,4,...), und schaltet die Maus auf die Hardwarenaheste Weise ab. Damit sollte die Funktion unter MultiTOS nicht mehr genutzt werden. STRIG(): Siehe STICK(). TT?: arbeitet fehlerhaft und führt unter bestimmten Umständen zum Absturz des Programms (fehlender Cookiejar, bzw. fehlender Cookie). btw: Wie arbeitet TT? eigentlich genau? _FPU, _CPU? Außerdem überschreibt TT? Teile des Programmcodes, ein Verfahren, das nun wirklich schmutzig ist. Selbstmodifizierende Programme sind MEGA-OUT! Verschiedentlich wurde auch berichtet, daß bei Benutzung von TT? größere Teile des Programmes überschrieben wurden. Nach kurzem Debuggen des entsprechenden Routine kann ich das weder ausschließen noch erhärten. VDIBASE: Die Funktion liefert m.W. seit TOS 1.02 keine vernünftigen Werte zurück. Abhilfen: Work_out-Feld, vqt_extend(). XBIOS(): XBIOS(2 ... 5) sollten nicht mehr genutzt werden. Die Abfrage und das Setzen der Bildschirmadresse kann auf diversen Graphikkarten nicht funktionieren, XBIOS(4) ist nur für die Standardauflösungen definiert. _C, _X, _Y: Liefern im compilierten Programm 0 zurück. Abhilfe: In GEM-Programmen entweder die Werte aus dem WORT_OUT-Feld benutzen oder, besser noch, den Bereich des Hintergrundfensters mit WIND_GET erfragen. Die Anzahl der Farbebenen kann man z.B. dem AES-Globalfeld entnehmen. Übrigens ist dieser Fehler (wie auch diverse andere) GFA seit über einem Jahr bekannt. Hinweis a): Mir ist klar, daß STICK und STRIG für Spiele durchaus noch eine Existenzberechtigung haben. Unter GEM jedoch sollte man darauf verzichten! Hinweis b): Auch wenn man keine LA-Befehle verwendet, rufen sowohl der Interpreter als auch der Compiler LA auf. Abhilfe schafft nur ein Patch, siehe dazu unter Punkt 7. Gruppe: GFABASIC ID : A1725@PB2 Kommentar zu A9378@OS Wg. : Bugs: Teil 3 Von : Uwe Ohse @ PB2 (Fr, 16.04.93 10:17) 5. Compileroptionen: - $B+ "Fängt Bombenfehler ab" Hierfür werden diverse Vektoren verbogen. Die Anwendung dieser Option in Accessoires verbietet sich also von selbst ("Accessoires should not steal vectors"), sonst hagelt es Abstürze beim Auflösungswechsel. Es ist eigentlich überflüssig zu bemerken, daß selbstverständlich weder XBRA noch SETEXC verwenden wird. Also darf diese Option unter MiNT nicht verwendet werden, oder der Absturz unter MiNT (und MultiTOS) ist nur eine Frage von Millisekunden. - $I+ "Interruptroutinen einschalten" verbiegt Kbdvbase()->ikbdsys. Verbietet sich in Accessoires also ebenfalls. Auch hier wird natürlich weder XBRA noch setexc benutzt, und unter MiNT lauffähig sind Programme, die mit dieser Option compiliert wurden, auch nicht. Diese Option sollte man also ebenfalls besser nicht setzen. Aber: Das Setzen von $I- führt zu einigen Nebenwirkungen: -- Every und After können nicht mehr benutzt werden. Im Ernstfall kann man sie aber über EVNT_TIMER() nachbilden. -- CTRL/ALT/SHIFT funktioniert nicht mehr (kein Verlust, ist unter MiNT sowieso nicht zu gebrauchen) -- RESUME und RESUME NEXT werden unbenutzbar. Einzig RESUME marke kann noch verwendet werden, löscht aber den bugsicinternen Stack und sollte nur ins Hauptprogramm oder eine Prozedur, die garantiert nicht per RETURN verlassen wird, führen. -- $m Speicherbedarf festlegen $m bestimmt den Speicherplatz, den das compilierte Programm für Variablen und als Stack etc. verwenden soll. Nicht dazu zählt der Platz für Programmcode und Konstanten (Strings, Festzahlen ...). Ein $m5000 beschränkt also den Platz im BSS-Segment auf 5000 Bytes und sorgt auch dafür, daß das compilierte Programm nicht noch weiteren Speicher mit Malloc an sich reißt. Sehr sinnvoll ist diese Option für Programme, die unter Multitos laufen sollen oder Accessoires. [Siehe außerdem RESERVE] Es gibt keine Möglichkeit, aus Bugsic herauszukitzeln, wieviel Speicher ein Programm denn benötigt. Die Mühe muß man sich leider selbst machen. - Man könnte im Interpreter in einer mit EVERY "kleiner Zeitabschnitt" aufgerufenen Funktion das Maximum gleichzeitig belegten Speichers bestimmen. - Natürlich kann man sich diesen Wert auch berechnen. In der Praxis ist das relativ einfach, da man sein Programm ja schließlich ordentlich vorbereitet hat und dabei natürlich aus der Programmdokumentation den Umfang aller Variablen und Strukturen sowie ihre Lebenszeit entnehmen kann ;-) Auf jeden Fall sollte man eine ausreichende Sicherheitsspanne dazurechnen, denn aufgrund von Speichermangel entstehende Fehler können sehr schwer zu finden sein. Faustformel: Der benötigte Arbeitsspeicher ist "maximaler Speicherverbrauch aller Variablen und Felder" plus "Stackplatz" plus "sonstiger Verwaltungskram" plus "IO-Puffer" plus "Sicherheitsreserve". Speicherverbrauch der Variablen und Felder: Kann nur abgeschätzt werden (mankann aber auch mal mit EVERY danach forschen). Stackplatz: Sollte man recht hoch ansetzen, wenn man ein tief verschachteltesoder gar rekursives Programm hat. In letzterem Fall sollte man auch noch mal genauer über den Speicherbedarf der lokalen Variablen nachdenken! Sonstiger Verwaltungskram: Was Bugsic halt so braucht, z.B. den Platz für AES- und VDI-Parameterfelder. 5K reichen aber locker. IO-Puffer: Für jedes mit OPEN geöffnete File braucht Bugsic 4K Speicher. Reserve: Ein Sicherheitsabstand von ein paar K sollte für den Fall, daß mal mehr Speicher benötigt wird, als man gedacht hat, immer eingeplant werden. Der Speicherplatz für Resourcen wird mit "Malloc" alloziert, er braucht für $m also nicht berechnet zu werden. Denke aber daran, daß Resourcen bei ACC's frühzeitig geladen werden müssen - wie auch alle Mallocs am Programmstart getätigt werden müssen (erste AES-Aktion am Programmbeginn: WIND_UPDATE(BEG_UPDATE), RSC_LOAD(), MALLOC(), WIND_UPDATE(END_UPDATE)). Inlines stehen übrigens im Programmtext und brauchen also nicht berechnet zu werden. 6. Verschiedenes: - das INTIN-Array ist auf 120 Elemente begrenzt. Daraus ergibt sich, daß der Befehl TEXT nur Zeichenketten mit bis zu 120 Zeichen ausgeben kann, der Rest wird abgeschnitten. Ähnliches gilt für POLYLINE. Generell gilt dies für alle Befehle, die viele Koordinaten an das VDI übergeben. Das ist kein Bug, nur eine Beschränkung. 7. Hinweise auf weitere Quellen in rein zufälliger Reihenfolge: - Von Karsten Isakovic (Maus Berlin) kreist ein Text mit Tips über auflösungsunabhängiges Programmieren durch die Mailboxen. Unbedingt empfehlenswert!!! Er liegt zum Beispiel in der Quark Paderborn im Brett "Textfiles allgemein" als "PRG_TIPS.LZH". - Von Christoph Conrad (Maus Aachen 3) stammt eine Anleitung zum Patch des Compilers (genauer der Lib.) und Interpreters 3.6. Damit gelinkte Programme rufen keine LineA mehr auf, wenn der Programmierer die im Abschnitt 2 angegebenen LA-aufrufenden Befehle nicht verwendet. Auf der Grundlage dieser Anleitung habe ich ein Programm geschrieben, das die Patches an Interpreter und Compiler selbst durchführt. Es liegt als Buglafix.Zoo im Brett ST-Tools in der Quark Paderborn (05251/71409, Gastdownload frei). - Dann ist da noch die Professional-GEM-Serie von Tim Oren, die in vielen Mailboxen als PROGEM.LZH oder PRO_GEM.LZH zu finden ist. So unter anderem in der Quark Paderborn im Brett Textfiles Allgemein. Tim Oren ist einer der GEM-Programmierer, schon alleine deshalb ist der Text lesenswert. Er enthält allerhand wertvolle Tips. - Um den Interpreter unter MiNT zum Laufen zu bekommen, habe ich einen Patch der Kategorie "brutal und wirksam" geschrieben. Zumindest auf meinem TT funktioniert er, wenn auch prinzipbedingt deutlich instabiler als ein ungepatchter Interpreter. (Quark PB, Brett ST-TOOLS, Bugmntfx.zoo). - Um den Interpreter auch auf Graphikkarten wenigstens grundsätzlich zum Laufen zu bekommen, hat Frank Baumgart ein Tool geschrieben, das die diversen setscreens abfängt. Es liegt als BUGSSFIX.LZH im Brett ST-Tools in der Quark Paderborn. Falls jemand glaubt, ich mache Werbung für die Quark PB: So ist es :-) 8. Programmierung von Accessoires - Wie oben schon erwähnt: Die Benutzung von $B+ und $I+ ist verboten und führt beim Auflösungswechsel zum Absturz. - Das Beispiel-ACC im Handbuch zu Version 3.0 auf den Seiten 52 bis 53 ist fehlerhaft, der Block CASE 22,41 CLOSEW#1 exit!=TRUE sollte ersetzt werden in CASE 22 CLOSEW#1 exit!=TRUE CASE 41 exit!=TRUE Bei Eintreffen der Message 41 (AC_CLOSE) ist das Fenster schon geschlossen! - RESERVE ist im ACC's VERBOTEN! Ebenso muß man mit Malloc vorsichtig sein, da vom ACC's allozierter Speicher dem Hauptprogramm zugerechnet wird, und bei Beendigung der Applikation freigegeben wird. Wenn aber das allozieren von Speicher unbedingt notwendig ist, sollte man aber den WIND_UPDATE-Trick von Laurenz Prüßner verwenden. - Accessoires haben keine vollständige Basepage. Man sollte sich auf die Werte darin nicht verlassen. - Accessoires sind keine echten GEMDOS-Prozesse. Daraus ergeben sich eine Reihe unerfreulicher Folgen, eine davon haben wir oben schon kennen- gelernt (das Speicherproblem). Weitere Probleme: - die DTA (benutzt für FSFIRST/FSNEXT/EXIST) ist defaultmäßig dieselbe, die das laufende Hauptprogramm benutzt. Chaos kann die Folge sein! In Accessoires sollte es üblich sein, vor allen DTA-Operationen die DTA zu setzen! - ACCs können (ohne größeren Aufwand und schmutzige Tricks) keine Programme starten. 9. Programmierung MiNT- und MultiTOS-fester Programme - $I+ und $B+ sind unter MiNT tödlich - RESERVE kann nur einmal zum Verkleinern des Speichers benutzt werden, $m ist vorzuziehen - man darf keineswegs auf fremden Speicher zugreifen - Es ist nicht gesagt, daß zwei direkt nacheinander geMALLOCte Speicherblöcke im direkt aufeinander folgen - Fensterhandles können größer als nur 7 werden (MTOS) - Fensterelemente können auch im Hintergrund bedient werden. Programmiertip: Wird ein Pfeil oder ein Scrollbalken eines im Hintergrund liegenden Fensters betätigt, kann man die neuzuzeichnenden Teile des Fensters aus der Rechteckliste holen. 10. disclaimer: Ich, Uwe Ohse, übernehme keine Verantwortung für Korrektheit oder Vollständigkeit dieser Tips. Sollte sich durch ihre Anwendung irgendein Problem ergeben, bin ich, egal welches Art es ist und wie schlimm es auch sein mag, in keiner Weise dafür verantwortlich. 11. Dieser Text ist auf Grundlage meines heutigen Wissens entstanden. Ich bin gerne bereit, ihn zu korrigieren und zu ergänzen. Dazu brauche ich natürlich Mitarbeit! Die jeweils aktuellste Version dieser Mängelliste wird immmer im Brett 120 (Textfiles allgemein) in der Quark Paderborn liegen. 12. Alternativen: - Pure C (sehr schnell Compiler, sehr guter Debugger, sehr gute Onlinehilfe) - Lattice C (sehr gute Bibliotheken, schneller Compiler, hoch portabel, Weiterentwicklung fraglich) - GNU C (sehr gute Bibliotheken, langsamer Compiler, hoch portabel, kostenlos, alle Sourcen erhältlich, kein funktionierender Debugger, C++ ) - Hänisch Modula II (schnell, Onlinehilfe, sehr gute Libs, für Modula sehr portabel) - Pure Pascal (Turbo 6.0 kompatibel, sehr guter Debugger, Onlinehilfe, sehr schnell, Oberfläche Gift für MTOS) - GFA 4.0, sobald es fertig ist, könnte eine werden. Für die C-Compiler gibt es mittlerweile eine Unzahl von Librarys, mit denen man fast alle Probleme erschlagen kann. U.A. gibt es die MiNTLib, die eine MiNT-Unterstützung liefert, ohne daß die Programmierer etwas daran tun müßte, und auch garantiert, daß das Programm unter reinem TOS lauffähig ist. Der erzeugte Code ist bei allen oben genannten Systemen gut bis sehr gut.